home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1993
/
Internet Info CD-ROM (Walnut Creek) (1993).iso
/
inet
/
internet-drafts
/
draft-ietf-madman-mtamib-03.txt
< prev
next >
Wrap
Text File
|
1993-08-18
|
21KB
|
640 lines
Internet Draft
Mail Monitoring MIB
Ned Freed
Steve Kille
MADMAN Working Group
August 17 1993
Expires: February 17 1994
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com,
or munnari.oz.au.
Abstract
This document extends the basic Network Services Monitoring MIB [5]
to allow monitoring of Message Transfer Agents (MTAs).
The SNMP Network Management Framework
The SNMP Network Management framework is laid out in these four
documents:
STD 16 / RFC 1155 [1] Defines the generic structure of
RFC 1212 [2] network management information.
STD 15 / RFC 1157 [3] Defines the protocol for accessing
network management information.
STD 17 / RFC 1213 [4] Defines the primary set of managed
objects.
The framework is adaptable/extensible by defining newer MIBs to
suit the requirements of specific applications/protocols/situations.
MTA Objects
If there are one or more MTAs on the host, the following mta group may
be used to monitor them. Any number of the MTAs on a host may be
monitored. Each MTA is dealt with as a separate application and has
its own applTable entry in the Network Services Monitoring MIB.
The MIB described in this document covers only the portion which is
specific to the monitoring of MTAs. The network service related part of
the MIB is covered in a separate document [5].
Message Flow Model
A general model of message flow inside an MTA has to be presented
before a MIB can be described. Generally speaking, message flow occurs
in four steps:
(1) Messages are submitted to the MTA by User Agents, Message
Stores, other MTAs, and gateways.
(2) The "next hop" for the each message is determined. This is simply the
destination the message is to be delivered to; it may or may not be the
final destination of the message. Multiple "next hops" may exist for a
single message (as a result of either having multiple recipients or
distribution list expansion); this may make it necessary to duplicate
messages.
(3) Messages are converted into the format that's appropriate for the next
hop.
(4) Messages are delivered to the appropriate destination, which may be a
User Agent, Message Store, another MTA, or another gateway.
Storage of messages in the MTA occurs at some point during this
process. However, it is important to note that storage may occur at
different and possibly even multiple points during this process. For
example, some MTAs expand messages into multiple copies as they are
received. In this case (1), (2), and (3) all occur prior to storage.
Other MTAs store messages precisely as they are received and perform
all expansion and conversion processing during retransmission
processing. So here only (1) occurs prior to storage. This leads to a
situation where, in general, a measurement of messages received may
not equal a measurement of messages in store, a measurement of
messages stored may not equal a measurement of messages retransmitted,
or both.
MTA-MIB DEFINITIONS ::= BEGIN
IMPORTS
OBJECT-TYPE FROM RFC-1212
experimental, Counter, Gauge FROM RFC1155-SMI
DisplayString FROM RFC1213-MIB
applIndex, applProtoID FROM APPLICATION-MIB;
mta OBJECT IDENTIFIER ::= {experimental 47}
mtaTable OBJECT-TYPE
SYNTAX SEQUENCE OF MTAEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"The table holding information specific to an MTA."
::= {mta 1}
mtaEntry OBJECT-TYPE
SYNTAX MTAEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"The entry associated with each MTA."
INDEX {applIndex}
::= {mtaTable 1}
MTAEntry ::= SEQUENCE {
applIndex
INTEGER,
mtaSubmittedMessages
Counter,
mtaStoredMessages
Gauge,
mtaDeliveredMessages
Counter,
mtaSubmittedVolume
Counter,
mtaStoredVolume
Gauge,
mtaDeliveredVolume
Counter,
mtaSubmittedRecipients
Counter,
mtaStoredRecipients
Gauge,
mtaDeliveredRecipients
Counter
}
mtaSubmittedMessages OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of messages submitted since MTA initialization."
::= {mtaEntry 1}
mtaStoredMessages OBJECT-TYPE
SYNTAX Gauge
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of messages currently stored in the MTA."
::= {mtaEntry 2}
mtaDeliveredMessages OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of messages delivered since MTA initialization."
::= {mtaEntry 3}
mtaSubmittedVolume OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total volume of messages submitted since MTA
initialization, measured in kilo-octets. This volume should
include all transferred data that is logically above the mail
transport protocol level. For example, an SMTP-based MTA
should use the number of kilo-octets in the message header
and body, while an X.400-based MTA should use the number of
kilo-octets of P2 data."
::= {mtaEntry 4}
mtaStoredVolume OBJECT-TYPE
SYNTAX Gauge
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total volume of messages currently stored in the MTA,
measured in kilo-octets. This volume should include all
stored data that is logically above the mail transport
protocol level. For example, an SMTP-based MTA should
use the number of kilo-octets in the message header and
body, while an X.400-based MTA would use the number of
kilo-octets of P2 data."
::= {mtaEntry 5}
mtaDeliveredVolume OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total volume of messages delivered since MTA
initialization, measured in kilo-octets. This volume should
include all transferred data that is logically above the mail
transport protocol level. For example, an SMTP-based MTA
should use the number of kilo-octets in the message header
and body, while an X.400-based MTA should use the number of
kilo-octets of P2 data."
::= {mtaEntry 6}
mtaSubmittedRecipients OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of recipients specified in all messages
submitted since MTA initialization."
::= {mtaEntry 7}
mtaStoredRecipients OBJECT-TYPE
SYNTAX Gauge
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of recipients specified in all messages
currently stored in the MTA."
::= {mtaEntry 8}
mtaDeliveredRecipients OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of recipients specified in all messages
delivered since MTA initialization."
::= {mtaEntry 9}
-- MTAs typically group inbound submissions, queue storage, and
-- outbound deliveries in some way. In the most extreme case
-- information will be maintained for each different entity that
-- submits messages and for each entity the MTA stores messages for
-- and delivers messages to. Other MTAs may elect to treat all
-- submissions equally, all queue storage equally, all deliveries
-- equally, or some combination of this.
-- In any case, a grouping abstraction is an extremely useful for
-- breaking down the activities of an MTA. For purposes of labelling
-- this will be called a "group" in this MIB.
-- Each group contains all the variables needed to monitor all aspects
-- of an MTA's operation. However, the fact that all groups contain
-- all possible variables does not imply that all groups must use all
-- possible variables. For example, a single group might be used to
-- monitor only one kind of event (inbound processing, outbound
-- processing, or storage). In this sort of configuration all unused
-- counters would be left at zero.
-- Groups are mutually exclusive; a given event can only be reflected
-- by the counters of a single group.
-- The term "channel" is often used in MTA implementations; channels
-- are usually, but not always, equivalent to a group. However,
-- this MIB does not use the term "channel" because there is no
-- requirement that an MTA supporting this MIB has to map its
-- "channel" abstraction one-to-one onto the MIB's group abstration.
mtaGroupTable OBJECT-TYPE
SYNTAX SEQUENCE OF MtaGroupEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"The table holding information specific to each MTA group."
::= {mta 2}
mtaGroupEntry OBJECT-TYPE
SYNTAX MtaGroupEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"The entry associated with each MTA group."
INDEX {applIndex, mtaGroupIndex}
::= {mtaGroupTable 1}
MtaGroupEntry ::= SEQUENCE {
applIndex
INTEGER,
mtaGroupIndex
INTEGER,
mtaGroupSubmittedMessages
Counter,
mtaGroupRejectedMessages
Counter,
mtaGroupStoredMessages
Gauge,
mtaGroupDeliveredMessages
Counter,
mtaGroupSubmittedVolume
Counter,
mtaGroupStoredVolume
Gauge,
mtaGroupDeliveredVolume
Counter,
mtaGroupSubmittedRecipients
Counter,
mtaGroupStoredRecipients
Gauge,
mtaGroupDeliveredRecipients
Counter,
mtaGroupQueuedMtaAssociationIndex
INTEGER,
mtaGroupOldestMessageStored
TimeTicks,
mtaGroupInboundAssociations
Gauge,
mtaGroupOutboundAssociations
Gauge,
mtaGroupAccumulatedInboundAssociations
Counter,
mtaGroupAccumulatedOutboundAssociations
Counter,
mtaGroupLastInboundActivity
TimeTicks,
mtaGroupLastOutboundActivity
TimeTicks,
mtaGroupRejectedInboundAssociations
Counter,
mtaGroupFailedOutboundAssociations
Counter,
mtaGroupInboundRejectionReason
DisplayString,
mtaGroupOutboundConnectFailureReason
DisplayString,
mtaGroupScheduledRetry
TimeTicks,
mtaGroupMailProtocol
OBJECT IDENTIFIER,
mtaGroupName
DisplayString
}
mtaGroupIndex OBJECT-TYPE
SYNTAX INTEGER (1..2147483647)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The index associated with a group for a given MTA."
::= {mtaGroupEntry 1}
mtaGroupSubmittedMessages OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of messages submitted to this group since MTA
initialization."
::= {mtaGroupEntry 2}
mtaGroupRejectedMessages OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of messages rejected by this group since MTA
initialization."
::= {mtaGroupEntry 3}
mtaGroupStoredMessages OBJECT-TYPE
SYNTAX Gauge
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of messages currently stored in this
group's queue."
::= {mtaGroupEntry 4}
mtaGroupDeliveredMessages OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of messages delivered by this group since MTA
initialization."
::= {mtaGroupEntry 5}
mtaGroupSubmittedVolume OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total volume of messages submitted to this group since
MTA initialization, measured in kilo-octets. This volume
should include all transferred data that is logically above
the mail transport protocol level. For example, an
SMTP-based MTA should use the number of kilo-octets in the
message header and body, while an X.400-based MTA should use
the number of kilo-octets of P2 data."
::= {mtaGroupEntry 6}
mtaGroupStoredVolume OBJECT-TYPE
SYNTAX Gauge
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total volume of messages currently stored in this
group's queue, measured in kilo-octets. This volume should
include all stored data that is logically above the mail
transport protocol level. For example, an SMTP-based
MTA should use the number of kilo-octets in the message
header and body, while an X.400-based MTA would use the
number of kilo-octets of P2 data."
::= {mtaGroupEntry 7}
mtaGroupDeliveredVolume OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total volume of messages delivered by this group since
MTA initialization, measured in kilo-octets. This volume
should include all transferred data that is logically above
the mail transport protocol level. For example, an
SMTP-based MTA should use the number of kilo-octets in the
message header and body, while an X.400-based MTA should use
the number of kilo-octets of P2 data."
::= {mtaGroupEntry 8}
mtaGroupSubmittedRecipients OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of recipients specified in all messages
submitted to this group since MTA initialization."
::= {mtaGroupEntry 9}
mtaGroupStoredRecipients OBJECT-TYPE
SYNTAX Gauge
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of recipients specified in all messages
currently stored in this group's queue."
::= {mtaGroupEntry 10}
mtaGroupDeliveredRecipients OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of recipients specified in all messages
delivered by this group since MTA initialization."
::= {mtaGroupEntry 11}
mtaGroupQueuedMtaAssociationIndex OBJECT-TYPE
SYNTAX INTEGER (0..2147483647)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Reference into association table to allow correlation of this
group's active association with the association table. If
there is no active association for this group this value should
be 0."
::= {mtaGroupEntry 12}
mtaGroupOldestMessageStored OBJECT-TYPE
SYNTAX TimeTicks
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The time when the oldest message in this group's queue
was placed in the queue."
::= {mtaGroupEntry 13}
mtaGroupInboundAssociations OBJECT-TYPE
SYNTAX Gauge
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of current associations to the group, where the
group is the responder."
::= {mtaGroupEntry 14}
mtaGroupOutboundAssociations OBJECT-TYPE
SYNTAX Gauge
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of current associations to the group, where the
group is the initiator."
::= {mtaGroupEntry 15}
mtaGroupAccumulatedInboundAssociations OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of associations to the group since MTA
initialization, where the group is the responder."
::= {mtaGroupEntry 16}
mtaGroupAccumulatedOutboundAssociations OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of associations from the group since MTA
initialization, where the group was the initiator."
::= {mtaGroupEntry 17}
mtaGroupLastInboundActivity OBJECT-TYPE
SYNTAX TimeTicks
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Time since the last time that this group had an active
inbound association for purposes of message submission."
::= {mtaGroupEntry 18}
mtaGroupLastOutboundActivity OBJECT-TYPE
SYNTAX TimeTicks
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Time since the last time that this group had an
outbound association for purposes of message delivery."
::= {mtaGroupEntry 19}
mtaGroupRejectedInboundAssociations OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of inbound associations the group has
rejected, since MTA initialization."
::= {mtaGroupEntry 20}
mtaGroupFailedOutboundAssociations OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number associations where the group was the
initiator and association establishment has failed,
since MTA initialization."
::= {mtaGroupEntry 21}
mtaGroupInboundRejectionReason OBJECT-TYPE
SYNTAX DisplayString
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The failure reason, if any, for the last connection this
group refused to respond to. An empty string indicates that
the last attempt was successful. If no connection attempt has
been made since the MTA was initializaed the value should be
'never'."
::= {mtaGroupEntry 22}
mtaGroupOutboundConnectFailureReason OBJECT-TYPE
SYNTAX DisplayString
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The failure reason, if any, for the last connection attempt
this group initiated. An empty string indicates that the last
attempt was successful. If no connection attempt has been
made since the MTA was initializaed the value should be
'never'."
::= {mtaGroupEntry 23}
mtaGroupScheduledRetry OBJECT-TYPE
SYNTAX TimeTicks
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The scheduled time at which this group will next attempt to
make a connection. This time is relative to the query time."
::= {mtaGroupEntry 24}
mtaGroupMailProtocol OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"An identification of the protocol being used by this group.
For an group employing OSI protocols, this will be the
Application Context. For Internet applications, the IANA
maintains a registry of the OIDs which correspond to well-known
message transfer protocols. If the application protocol is not
listed in the registry, the value {applProtoID port} is used
where 'port' corresponds to the primary port being used by the
group."
::= {mtaGroupEntry 25}
mtaGroupName OBJECT-TYPE
SYNTAX DisplayString
ACCESS read-only
STATUS mandatory
DESCRIPTION
"A descriptive name for the group. If this group connects to
a single remote MTA this should be the name of that MTA. If
this in turn is an Internet MTA this should be the domain name.
For an OSI MTA it should be the string encoded distinguished
name of the managed object using the format defined in RFC-?.
For X.400(1984) MTAs which do not have a Distinguished Name,
the RFC-1327 syntax 'mta in globalid' should be used."
::= {mtaGroupEntry 26}
END
References
[1] Rose, M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based Internets", STD 16,
RFC 1155, Performance Systems International, Hughes LAN
Systems, May 1990.
[2] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
STD 16, RFC 1212, Performance Systems International, Hughes LAN
Systems, March 1991.
[3] Case, J., M. Fedor, M. Schoffstall, and J. Davin, "Simple
Network Management Protocol", STD 15, RFC 1157, SNMP Research,
Performance Systems International, Performance Systems
International, MIT Laboratory for Computer Science, May 1990.
[4] McCloghrie, K., and M. Rose, Editors, "Management Information
Base for Network Management of TCP/IP-based internets:
MIB-II", STD 17, RFC 1213, Hughes LAN Systems, Performance
Systems International, March 1991.
[5] Freed, N., Kille, S., The Network Services Monitoring MIB,
Internet Draft, August 1, 1993.
Expires: February 17, 1994